2016.09.30
==================
Aanpassingen zijn doorgevoerd met betrekking tot gebruik van minOccurs=0 en nillable=true. Deze worden niet meer in combinatie gebruikt. Een element is of optioneel of er kan de waarde null aan worden toegekend

StUF4_ent_ingeschrevenpersoon.xsd
- complexType Geboortedatum
  - minOccurs=0 verwijderd bij elementen maand en dag. Met minOccurs=0 krijgen maand en dag in een .NET implementatie van een provider by default de waarde 0. Het is beter om met de waarde null aan te geven dat
	geboorte- maand of dag onbekend is dan met de waarde 0
- complexType IngeschrevenPersoon
  - minOccurs=0 verwijderd bij elementen aanduidingNaamgebruik, adelijkeTitelPredikaat, overlijdensdatum en indicatieGezag
- complexType InOnderzoekIngeschrevenPersoonMetagegeven hernoemd naar InOnderzoek
- alle InOnderzoek complexTypes
  - bij alle boolean elementen is minOccurs=0 verwijderd en is default=false toegevoegd. Het optioneel maken van de boolean elementen voegt niets toe en zou de code complexer maken.
	In code zou in geval van minOccurs=0 eerst moeten worden gekeken of een element een waarde heeft en dan pas kan de waarde worden bevraagd. Door het verwijderen van minOccurs=0 is het in code niet meer nodig
	om de eerste check te doen
- complexType Periode
  - minOccurs=0 verwijderd voor element totEnMet
- simpleType Postcode
  - pattern aangescherpt. Een postcode bestaat uit 4 cijfers gevolgd door 2 hoofdletters
- complexType Verblijfstitel
  - minOccurs=0 verwijderd voor element datumEinde

StUF4_msg_ingeschrevenpersoon.xsd
- complexType ZoekIngeschrevenPersonenOpGeslachtsnaam
  - element voornamen hernoemd naar voornaam
  - nillable=true verwijderd bij element geboortedatum
  - minOccurs=0 bij element geslachtsaanduiding is vervangen met nillable=true. Met minOccurs=0 krijgt element geslachtsaanduiding in een .NET implementatie provider by default de waarde 'Man'. Het is hierdoor niet
	duidelijk of geslachtsaanduiding als zoekcriteria is opgegeven of niet. Met nillable=true kan null als waarde worden toegekend aan geslachtsaanduiding zoekcriteria
- complexType ZoekIngeschrevenPersonenOpPostcodeHuisnummer
  - element postcode is niet meer afgeleid van postcode type, zodat het niet dezelfde constraints heeft als de postcode type (4 cijfers gevolgd door 2 hoofdletters).
	Als postcode filter kan 4 cijfers gevolgd door eventueel een spatie en 2 hoofd- of kleine letters
  - minOccurs=0 bij element huisnummer is vervangen met nillable=true.
  - element periode is toegevoegd
- complexType RaadpleegIngeschrevenPersoon
  - element peildatum hernoemd naar periode

2016.09.25
==================
Aanpassingen zijn doorgevoerd om de complexiteit van de gegenereerde code terug te brengen. De oude Response berichten die dienden als wrappers om de gevonden ingeschreven personen zijn vervangen door
een ingeschreven persoon collectie element. Om dezelfde reden is RaadpleegIngeschrevenPersoonResponse bericht vervangen door een ingeschreven persoon element.

StUF4_ent_ingeschrevenpersoon.xsd
- complexType CorrespondentieAdres hernoemd naar Correspondentieadres
- complexType IngeschrevenPersonenBeperkt toegevoegd
- complexType IngeschrevenPersoon
  - attribute nillable="true" toegekend aan element aanduidingNaamgebruik zodat deze de waarde null kan worden toegekend
  - element correspondentieAdres hernoemd naar correspondentieadres
  - element verblijfstitels hernoemd naar verblijftitel. Een ingeschreven persoon kan maar 1 actuele verblijftitel hebben
  - element verblijftitel is nu van het type Verblijftitel in plaats van VerblijfstitelRelatie. Een Verblijfstitel is geen entiteit maar een kenmerk van een ingeschreven persoon. VerblijfstitelRelatie is verwijderd
  - attribute nillable="true" toegekend aan element indicatieGezag zodat deze de waarde null kan worden toegekend
- simpleType IndicatieGezag. Alle enumeratie waarden hebben de prefix x_ gekregen, zodat in code de enum wordt gegenereerd (Java) en omdat in .NET en Java de naam van een enum waarde niet kan beginnen met een cijfer

StUF4_msg_ingeschrevenpersoon.xsd
- element ZoekIngeschrevenPersoonOpGeslachtsnaam hernoemd naar ZoekIngeschrevenPersonenOpGeslachtsnaam
- element ZoekIngeschrevenPersoonOpGeslachtsnaamResponse is verwijderd
- element ZoekIngeschrevenPersoonOpPostcodeHuisnummer hernoemd naar ZoekIngeschrevenPersonenOpPostcodeHuisnummer
- element ZoekIngeschrevenPersoonOpPostcodeHuisnummerResponse is verwijderd
- element ZoekIngeschrevenPersoonOpBinnenlandsVerblijfsadres hernoemd naar ZoekIngeschrevenPersonenOpBinnenlandsVerblijfsadres
- element ZoekIngeschrevenPersoonOpBinnenlandsVerblijfsadresResponse is verwijderd
- element RaadpleegBewoningResponse is verwijderd
- element IngeschrevenPersonen is toegevoegd
- element peilDatum van RaadpleegIngeschrevenPersoon element is hernoemd naar peildatum
- element RaadpleegIngeschrevenPersoonResponse is verwijderd
- element IngeschrevenPersoon is toegevoegd

StUF4.wsdl
- alle ZoekIngeschrevenPersoon messages zijn hernoemd naar ZoekIngeschrevenPersonen messages
- alle Zoek[xxx]Out hebben als body part een element van het type IngeschrevenPersonen
- RaadpleegBewoningOut heeft als body part een element van het type IngeschrevenPersonen
- RaadpleegIngeschrevenPersoonOut heeft als body part een element van het type IngeschrevenPersoon
- alle ZoekIngeschrevenPersoon operaties zijn hernoemd naar ZoekIngeschrevenPersonen operaties

Opmerkingen:
- Wanneer een provider wordt geimplementeerd op basis van de gegenereerde .NET code, en de WSDL van de provider wordt opgehaald via de endpoint,
dan lijkt het of de provider geen operaties ontsluit. Dit wordt veroorzaakt doordat de .NET code generator (svcutil) de attribute 'ReplyAction="*"'
toevoegt aan elke operatie. Deze kan verwijderd worden en zorgt er ook voor dat de operaties zichtbaar zijn in de wsdl bevraagd via de provider endpoint
- Een referentie provider en consumer is toegevoegd aan de .NET solution.

2016.08.09
==================
Bij Verblijfstitel is periode kenmerk verwijderd. Kenmerken ingangsdatum en datumEinde (optioneel) zijn toegevoegd
Element VerblijfstitelRelatie is geintroduceerd. Deze is conform de andere entiteiten waar historie mogelijk is
Bij IngeschrevenPersoon is verblijfstitels kenmerk van type VerblijfstitelRelatie in plaats van type Verblijfstitel

2016.08.08
==================
Bij AdresBinnenland is aanduidingBijHuisnummer hernoemd naar locatieAanduiding
Bij VerblijfplaatsInOnderzoek is aanduidingBijHuisnummerInOnderzoek hernoemd naar locatieAanduidingInOnderzoek

Bij IngeschrevenPersoon is kind hernoemd naar kinderen, ouder naar ouders, nationaliteit naar nationaliteiten, verblijfplaats naar verblijfplaatsen, verblijfstitel naar verblijfstitels

Opmerkingen:
- Verblijfstitel is niet gemoduleerd als een relatie, omdat verblijfstitel niet kan bestaan zonder een IngeschrevenPersoon. En er zijn geen unieke verblijfstitels en een verblijfstitel kan niet worden 'gedeeld'
  met andere ingeschreven personen.
  Mogelijk is de verwarring ontstaan omdat een Periode entiteit is gebruikt om de ingangsdatum en datumEinde van de verblijfstitel aan te geven.
  Mogelijk is het beter om periode te verwijderen en twee datum kenmerken hiervoor te definieren.

2016.08.04
==================
Bij Periode is er voor kenmerk 'totEnMet' nillable="true" attribuut toegevoegd, zodat er in code geen waarde opgegeven hoeft te worden.

Bij Geboortedatum is er voor kenmerk 'Maand' en 'Dag' nillable="true" attribuut toegevoegd, zodat er in code geen waarde opgegeven hoeft te worden.

De collectie kenmerken kind, ouder, partner nationaliteit, verblijfplaats, verblijfstitel van IngeschrevenPersoon zijn hernoemd. Enkelvoud in plaats van meervoud, dus kind in plaats van kinderen, ouder in plaats van ouders.

Bij kind-, ouder- en partner in onderzoek heb ik een aantal aannames gemaakt. Kloppen deze aannames?
- Een ingeschreven persoon kan meerdere kinderen hebben. Daarom is er bij KindInOnderzoek een kenmerk (burgerservicenummerKind) opgenomen om aan te kunnen geven welk kind in onderzoek staat
- Een ingeschreven persoon kan maximaal 4 ouders hebben. Daarom is er bij OuderInOnderzoek een kenmerk (burgerservicenummerOuder) opgenomen om aan te kunnen geven welke ouder in onderzoek staat
- Een ingeschreven persoon kan maar 1 actuele partner hebben. Daarom is het bij PartnerInOnderzoek niet nodig om een kenmerk op te nemen om aan te geven welke partner in onderzoek staat

Een ingeschreven persoon kan meerdere nationaliteiten hebben. Hoe kunnen we aangeven welke nationaliteit in onderzoek staat?
Dit geldt volgens mij ook voor reisdocumenten. Is het nummer van het reisdocument uniek en kan deze als sleutel worden gebruikt?

Bij verblijfstitel, gezagsverhouding en verblijfplaats is ervan uit gegaan dat er maar 1 actueel kan zijn en is het niet nodig om een sleutel te hebben om bijvoorbeeld aan te geven welke verblijfplaats in onderzoek staat

Bij ZoekIngeschrevenPersoonOpGeslachtsnaam is er voor kenmerk 'geboortedatum' nillable="true" attribuut toegevoegd, zodat er in code geen waarde opgegeven hoeft te worden.

Bij ZoekIngeschrevenPersoonOpBinnenlandsVerblijfsadres is kenmerk 'openbareRuimteNaam' hernoemd naar 'openbareruimtenaam'. Hetzelfde is gedaan voor 'openbareruimteNaam' van AdresBinnenland

ZoekIngeschrevenPersoonOpAddresseerbaarIdentificatieObject is hernoemd naar RaadpleegBewoning

Openstaande technische punten die bekeken moeten worden:
- bij code generatie in C# worden xxxFieldSpecified kenmerken gegenereerd voor optionele object elementen. Echter dit gebeurt ook als wordt aangegeven dat zij nillable zijn, terwijl dit niet meer nodig is
- bij code generatie in C# worden er xxxResponse classes gegenereerd die eindigen met 1. Voorbeeld: RaadpleegIngeschrevenPersoonResponse1. Uitzoeken of dit kan worden aangestuurd, zodat dit niet gebeurt.